1. Technical Field
The present invention relates to service composition.
2. Discussion of the Related Art
Automatic service discovery and composition is one promise of Service Oriented Architecture (SOA) that is hard to achieve in practice. Currently, composition is done with graphical tools by manually selecting services and establishing their interactions. Business Process Execution Language (BPEL)-WS has been developed to describe composite services. However, describing composite services using BPEL-WS is tedious and requires extensive knowledge of the services being composed.
Automatic composition work has been focusing on composition using simple compatibility constraints, as well as semantic descriptions of services, such as Ontology Web Language (OWL)-S. The drawback of these approaches is that they do not provide an easy way of interacting with the composer/user. For example, even if the user is goal-oriented and does not require knowledge of services, the user must be familiar with the ontology that was used to describe the services. In addition, it is difficult for novice users to create goal specifications, since that involves studying the ontology to learn the terms the system uses. Further, the ontology does not automatically provide a method for verifying the requests. Hence, users do not have any guidance from the system that could help in specifying requests. This turns service composition into a tedious trial and error process.
With certain drawbacks of automatic service discovery and composition having been discussed, we will now introduce web services and follow that with a more detailed discussion of several approaches that may be used to compose the web services.
Web Services and Web Service Composition
According to the definition by World Wide Web Consortium (W3C), a web service is a software system designed to support interoperable machine-to-machine interaction over a network. Some definitions of web services appearing in the literature also require that the communications between machines is represented as eXtensible Markup Language (XML) messages following a Simple Object Access Protocol (SOAP) standard. Some definitions may also require that there is a machine-readable description of a service represented, for example, in Web Services Description Language (WSDL). Other specifications define protocols for publishing and discovering metadata about web services that enable applications to find them, either at design time or runtime, e.g., Universal Description Discovery and Integration (UDDI).
For purposes of this disclosure, we will use the most general definition that does not require SOAP, WSDL, or machine-readable descriptions of services. One example of web services that are not using SOAP and WSDL standards are REST (Representational State Transfer) web services, also referred to as RESTful web services in the literature. REST web services have become popular recently with the implementations made accessible to the public over the Internet, for example, by Amazon, Google and Yahoo. A description of the REST approach can be found, for example, in Leonard Richardson and Sam Ruby, “RESTful Web Services”, O'Reilly Media, Inc. (May 8, 2007). This type of architecture has led to the emergence of the term Web-Oriented Architecture (WOA) used to emphasize their web oriented characteristics from the more generic term SOA.
Web services can be combined to provide a new composite service. The composite service can be made available as a service itself. One example of a software product that provides tools for web service composition is IBM™ WEBSPHERE™ Business Integration Server.
A number of web service flow languages have been developed to describe compositions of web services, including Business Process Execution Language for Web Services (BPEL4WS), Web Service Choreography Interface (WSCI), and others. The flow languages represent the flow of messages between web services, and can be used to describe composite services.
In addition to web services there are several other approaches to dealing with machine-to-machine interactions. More basic efforts include XML-RPC (Remote Procedure Call), a precursor to SOAP that was only capable of RPC, and various forms of HTTP usage without SOAP. More ambitious efforts like Common Object Request Broker Architecture (CORBA) and Distributed Component Object Module (DCOM) provide frameworks to enable distributed objects written in multiple languages running on multiple computers to interoperate.
Generalized Service Composition
A more general form of web service composition is what we refer to as generalized service composition. Generalized service composition allows composing services accessible via a network, such as web services, or via other over-the-network communication approaches, such as RPCs, together with program code executed locally on a computer where the composed service is deployed. In systems following this convention, a service is any computer code that can receive requests and optionally respond by returning results. For example, IBM™ Project Zero includes the Assemble Zero sub-component that provides a general flow language and execution runtime for generalized service composition.
Project Zero introduces a simple environment for creating, assembling and executing applications based on popular Web technologies. The Project Zero environment includes a scripting runtime for Groovy and PHP with application programming interfaces optimized for producing REST-style services, integration mash-ups and rich Web interfaces. Project Zero is an incubator project started within IBM™ that is focused on the agile development of the next generation of dynamic Web applications. At the core of Project Zero is a full-stack platform optimized for Web applications. The Project Zero platform is further extended with Project Zero sub-components specialized for specific web-application programming patterns.
The Project Zero Assemble sub-component provides the capability to access different services and assemble them into a Project Zero application. It can be used in a variety of different ways. For example: constructing a feed style application that processes and aggregates a set of feeds from different sources; constructing a conversational application that coordinates interactions with services; and allowing Project Zero applications to access services through a common application programming interface (API).
It is sometimes useful to associate functions such as transformation, routing and logging with existing services. The Assemble framework enables this type of functionality that it calls mediation.
The functionality for constructing applications that produce feeds or conversational applications is provided through the flow sub-component. This is an optimized and highly specialized flow engine for processing data feeds, and coordinating interactions with other services.
A Project Zero Assemble flow graph is formed as a selection of modules called activities, where each module may appear once, more than once, or not at all. Each module included in the flow graph can be individually configured. The modules forming the flow graph must be connected. The connections are established between producing and receiving endpoints of the same type respectively called outputs and inputs of the activities.
Project Zero provides a collection of built-in activities, which can be extended with user-defined activities. Built-in activities that are immediately available are listed below.
Action—is a generic activity for calling a static operation on a specified Java class. The inputs of the action form the parameters, the outputs are the result of the action.
GET—performs an HTTP GET. It has no input. Its output is the value of the response returned from the service.
POST—performs an HTTP POST. It has at most one input: the body of the post request. Its output is the value of the response returned from the service.
DELETE—performs an HTTP DELETE. It has no input or output.
ReceivePOST—a receive activity that consumes HTTP POST requests sent to the process that matches its optional URL fragment. The output of a receive activity is the value of the received message. It has no input.
ReplyPOST—a replyPOST is an activity that provides the response to an HTTP POST request previously matched to a receive activity. Its input is the value sent in the response. It has no output and at most one input. The value of the input is what will be sent in the response.
Receive-replyPOST—a receive-replyPOST activity is a combination of a receivePOST immediately followed by a replyPOST. Its output is the value of the received message. Its input is the same as for reply; the value sent in the response.
receiveGET, replyGET, and receive-replyGET—are similar to their POST counterparts, but for HTTP GET instead of HTTP POST.
While—a structured loop. The condition is evaluated when the loop is activated. If the condition is true, the activities inside the loop are activated (respecting the order specified by their links). Once all activities inside the loop have completed or disabled, the condition is evaluated again. This repeats until the condition evaluates to false, at which point navigation continues based on the links leaving the while activity itself. It has no input and no output variable.
Pick—a pick activity provides the ability for external choice. It contains a variable name and an ordered list of choices, each one corresponding to an external request. It has no input. Its output is a variable consisting of two parts: 1) either the name of the choice if one is present, or the numerical index of the choice; and 2) if the choice is based on an incoming message, then the incoming message's body is placed in the message part of the pick's output variable. If the choice itself also specifies a variable, then a copy is placed in that variable as well.
Assign—assignment allows initialization of variables and copying of values from one variable to another. As an assign can copy from and to multiple locations, it has no implicit input or output.
Empty—the empty activity implies no processing other than the navigation implied by its connection to other activities through links. It is provided to help create specific navigational patterns. The output of an empty activity is null. It has no input.
Automatic Composition
Similarly to how programs can be composed of operators and functions, composite services describe service invocations and other low-level constructs. Composite services are processing graphs composed of smaller service components. A service component can be an invocation of an existing service, an external data input (e.g., a user-specified parameter or data source), a data processing operator (e.g., an arithmetic operator), or an other (smaller) composite service specified as a processing graph of service components.
While many execution environments include tools that assist users in defining composite services, these tools typically require detailed definitions of the processing flow, including all service components and communication between the components. One example of this type of tool is IBM™ WEBSPHERE™ Studio.
In contrast, methods such as planning can be used to automatically compose new composite services based on a high level input provided by the user. Automatic composition methods require less knowledge about the service component and in general only require the user to specify the composition goal in application domain terms.
For purposes of automatic composition, in many scenarios the service components can be described in terms of their data effects and preconditions. In particular, we assume that a description (such as WSDL or JAVA™ object code with optional metadata annotations) of each service component specifies the input requirements of the service component (such as data type, semantics, access control labels, etc.). We refer to these input requirements as preconditions of service invocation, or simply preconditions. The description also specifies the effects of the service, describing the outputs of the service, including information such as data type, semantics, etc. In general, a component description may describe outputs as a function of inputs, so that the description of the output can only be fully determined once the specific inputs to the component have been determined. Note that in practical implementations the invocations can be synchronous, such as subroutine of RPCs, or asynchronous, such as asynchronous procedure calls or message exchange or message flow.
Under these assumptions, an automated planner can then be used to automatically assemble processing graphs based on a user-provided description of the desired output of the application. The descriptions of the components are provided to the planner in the form of a domain description. The planner can also take into account the specification of available primal inputs to the workflow, if not all inputs are available for a particular planning request.
The planner composes the workflow by connecting components, starting from the primal inputs. It evaluates possible combinations of components, by computing descriptions of component outputs, and comparing them to preconditions of components connected to the output. More than one component input can be connected to one component output or one primal input. Logically, this amounts to sending multiple copies of data produced by the component output, with one copy sent to each of the inputs. In practical implementation these do not have to be copies, and it is possible to pass data by reference instead of by value. The process terminates when an output of a component (or a set of outputs taken together) satisfy the conditions specified in the user goal requirement. Note that all conditions are evaluated at plan time, before any applications are deployed or executed.
If multiple alternative compositional applications can be constructed and shown to satisfy the same request, the planner may use heuristics and utility functions to rank the alternatives and select the highest ranked plans.
The application, once composed, is deployed in an execution environment and can be executed one or more times.
Examples of a planner and an execution environment are described in Zhen Liu, Anand Ranganathan and Anton Riabov, “A Planning Approach for Message-Oriented Semantic Web Service Composition”, in AAAI-2007.
Similar work has been done in the contexts of Stream Processing and Grid Computing.
Faceted Search
Faceted search methods use tags to define the scope of user interaction with a system. However, faceted search is limited to searching over existing information represented, for example, as documents, web pages or feeds.
One notable example of a faceted search interface is FLAMENCO search. An overview of interfaces for managing faceted search is presented in Marti Hearst, Design Recommendations for Hierarchical Faceted Search Interfaces, ACM SIGIR Workshop on Faceted Search, August, 2006.